Häufigste Auslöser von ERP-Projekten sind Unzulänglichkeiten in der Abwicklung des Tagesgeschäftes, der Ruf nach Automatisierungen und speziell der Wunsch, in jeder Situation über die richtigen Informationen zu verfügen. Dazu kommt eine allgemeine Verunsicherung in Bezug auf die Tauglichkeit der bestehenden EDV.
Die Begründung von ERP-Ablösungsprojekten ist dann oft die, dass die bestehende Software kompliziert sei, an ihre Grenzen stosse und nicht mehr dem heutigen IT-Standard entspreche.
Mit den Projekten ist die Erwartung verbunden, dass die vorhandenen Mängel und Lücken durch den Einsatz moderner Anwendungssoftware und Technologie beseitigt werden und dass effiziente Geschäftsabläufe entstehen.
Das Pflichtenheft für die neue Software entsteht meist aus einer Sammlung von Anwenderwünschen, welche empfundene Mängel und Idealvorstellungen wiedergeben. Dazu kommen informatiktechnische Forderungen die den state of the art beschreiben.
Bei der Abklärung in Frage kommender ERP-Systeme werden die technologischen Aspekte in den Vordergrund gestellt. Diesbezügliche Vorlieben der "Experten" wirken vorentscheidend. Ein Teil der Angebote, oder alle bis auf eines, finden dann bereits hier ihren Evaluationstod.
Mit den verbleibenden Angeboten beschäftigen sich die Fachbereiche. Jeder aus seiner Sicht und nach seinen Prioritäten. Die Anbieter der Systeme beantworten Fragen und demonstrieren punktuelle Funktionalität. Es liegt in der Natur der Sache, dass man sich dabei auf der Oberfläche bewegt.
Wenn die entscheidungsrelevanten Personen ihre Erwartungen bestätigt glauben, und die kritischen Frager in die Ecke der "Detailkrämer" oder "EwigGestrigen" gestellt sind, fällt der Entscheid für ein System.
Die nun folgende Organisation der Realisierung ist geprägt von Projekt-Management-Methodik. Die zentralen Erfolgsfaktoren werden in der minuziösen Planung von Aktivitäten und einer engen Fortschrittskontrolle gesehen. Entsprechend dominieren im Projektplan Tätigkeiten und Termine.
Das Projektteam umfasst eine grössere Zahl Personen, weil man ja das Wissen vieler einbringen möchte und sich damit auch eine breite Akzeptanz ausrechnet.
In der Realisierungsphase zeigt sich, dass der Aufwand unterschätzt wurde. Es stellen sich nämlich Fragen und es treten Probleme auf, die man so nicht erwartet hat. Die Vorstellung von einem "Standard" erleidet Schiffbruch. Drei von fünf ERP-Projektrealisierungen münden in ein Hinbiegen und zwangsweises Zufriedengeben. Die wirklichen Probleme werden nicht gelöst, sondern umgeschichtet. Oft besteht das Mehr der neuen Organisation darin, dass die ungelösten Probleme besser verwaltet werden können. Zusätzliche Anwendungen und die neue Systemoberfläche vermögen dann eine Zeit lang über den eigentlichen Misserfolg hinwegzutäuschen.
Eine ERP-Software sagt nicht, wie etwas gemacht werden soll. Vielmehr handelt es sich um einen Funktionen-Baukasten, gekoppelt an eine alle Anwendungsgebiete übergreifende Datenbank.
Der in ERP-Systemen gerne verwendete Prozess-Begriff bezeichnet meist Funktionen-Ketten, oft auch nur einzelne Funktionen. Mit der Auswahl an Funktionen und Daten lassen sich unterschiedliche Lösungen für ein und dieselbe Aufgabe einrichten. Das heisst, dass zuerst einmal die sachlichen Verfahrenskonzepte benötigt werden. Sie bilden auch die Grundlage, um aus dem enormen Umfang der Datenbank diejenigen Stammdaten und zu erzeugenden Sekundärdaten zu erkennen, welche das System geschäftsspezifisch zutreffend und durchgängig machen.
Die Vorstellung, dass die Gliederung in Module es erlaubt, unabhängig Modul nach Modul einzuführen, ist ein gängiger Irrtum. Es gehört ja gerade zum Wesen integrierter Systeme, dass Daten dort bereitgestellt werden, wo sie originär erfassbar oder erzeugbar sind, und dies verlangt eine alle Teilsysteme einbeziehende Konzeption.
Eine Aufzählung, in welchen Bereichen die bestehende Organisation unbefriedigende Resultate zeitigt, hilft wenig, wenn nicht aufgedeckt wird weshalb. Auch detaillierte Ist-Analysen im Sinne einer Beschreibung der bestehenden Abläufe, schaden oft mehr als sie helfen, indem sie den Blick auf die Kernprobleme verdecken.
Es geht um das Erkennen der geschäftsrelevanten Teilsysteme und dabei der Mängel und Lücken. Hier stehen nicht Informatikfragen im Vordergrund, sondern die fachlichen Verfahren zur Planung, Abwicklung und Kontrolle "des Geschäftes". Deren geschäftsspezifische Tauglichkeit entscheidet über Effektivität und Effizienz. Um beispielsweise in einem Fertigungsbetrieb dem Problem der Terminverzüge zu begegnen, ist es unerlässlich, das sachbezogene Verfahren zur terminlichen Einplanung und Durchlaufsteuerung der Aufträge zu überprüfen. Welches sind die relevanten Rahmenbedingungen? Welche Regeln befolgen wir heute? Und daraus: Was machen wir falsch? Erst dadurch ergibt sich, ob der Hebel beim Verfahren selbst, oder bei dessen Umsetzung in der Software anzusetzen ist.
Für einen erfolgreichen ERP-Systemeinsatz bedarf es konkreter Vorgaben für die Ausgestaltung; ein Systemkonzept. Die oft angetroffene Vorstellung, dass die Systemspezialisten vorzu die relevanten Fragen stellen und die Fachspezialisten jeweils die Antwort darauf geben, und so das Gesamtsystem entsteht, ist irreführend. Auf diese Weise wird lediglich neu mechanisiert, nicht organisiert.
Wer den Beitrag des ERP-Systems zum Geschäftserfolg ins Zentrum stellt, benötigt ein Konzept, welches Strategien und Geschäftsprozesse in eine Systemstruktur, in Verfahren und in Daten umsetzt. Dabei geht es beileibe nicht darum, sämtliche Details aller Anwendungsgebiete schon zum voraus festzulegen. Dies ist schlicht nicht möglich, weil ein ERP-Projekt stets nicht vorhersehbare Probleme aber auch Chancen bereithält.
Geschäftsstrategien sind Papiertiger, wenn die operative Organisation sie nicht umsetzen kann. Es geht deshalb um treffende Organisation der Abwicklung und Kontrolle, und in erster Priorität im Bereich des Tagesgeschäftes. Dabei ist permanent eine ganzheitliche Sicht und das Erkennen von Zusammenhängen erforderlich. Die klassische Falle bildet hier die additive Teambildung, wenn möglichst viele sogenannte Wissensträger ins Projektteam delegiert werden, mit dem Effekt, dass eine Menge Ausgestaltungsdetails eingebracht werden, aber keine grundlegenden und abgestimmten Lösungen erarbeitet werden. Die Verantwortung ist aufgesplittert, also nicht vorhanden.
Bei der Auswahl des Projektleiters erfolgt oft eine Fixierung auf die Führungskompetenz. Ein gesundes Mass an Führungskompetenz gehört selbstverständlich dazu. Der Projektleiter muss aber in erster Linie dafür sorgen, dass zu lösende Aufgaben, Zusammenhänge und Rahmenbedingungen aufgedeckt werden, und dass die jeweiligen Lösungen aus der Sicht des Gesamten getroffen werden. Das erfordert Geschäftswissen, Organisationstalent und auch die Fähigkeit sich im Baukasten der Standardsoftware zurechtzufinden. Ohne Letzteres ist auch keine zielführende Zusammenarbeit mit den eigenen Informatikern und mit externen Systemspezialisten möglich.
Übergeordnete Projektinstanzen, unter welchem Titel sie auch immer gebildet werden, fördern die Qualität und den Ablauf des Projektes nur dann, wenn sie sich mit sachbezogener Übersicht und genügend Zeit ausrüsten. Auf reine "Appellationsgerichte" für situative Schlichtungen und Entscheidungen ist zu verzichten.
© PROJEKT-SUPPORT Gerhard Mäder und Partner AG